feat: Credit Sales Summary + per-customer Items on Credit tab - #323

This pull request has been automatically marked as stale because it has not had recent activity for 21 days.

To keep this PR open, please:

• Rebase on the latest develop branch
• Address any pending review comments
• Reply with an update on the PR status

If no further activity occurs within the next 14 days, this PR will be automatically closed.

Nice Feature..

Nice Feature..

Why are my PRs never merged? I'd like to contribute to this repo — I have a lot of ideas to help improve the UX, but I'm getting discouraged after more than 5 of my PRs went unreviewed

@MohamedAliSmk @MostafaKadry

Thanks @NotAbdelrahmanelsayed for your contribute, this is code review for your feature

Code review: dd0db844 (PR #323)

Feature shape is solid (summary list → per-customer statement/items → FIFO pay), with real reuse of get_customer_balance / partial payments. Several issues will break or mislead the pay / summary flows.

Confirmed break (Pay Due)

				pe_name = create_payment_entry(
					invoice_name=inv_name,
					amount=alloc_amount,
					mode_of_payment=mode,
					payment_account=account,
					pos_opening_shift=pos_opening_shift,
				)

create_payment_entry only accepts: invoice_name, amount, mode_of_payment, payment_account, reference_no, remarks, posting_date.

What’s good

• Balance math matches credit_sales.get_customer_balance (positive outstanding vs return credit).
• Batch item fetch for statements; Arabic search helper; rail wiring and translations look coherent.
• Savepoint around FIFO allocation is the right pattern (once the call signature is fixed).

Suggested merge blockers

1. Remove invalid pos_opening_shift= (or extend create_payment_entry and actually link PE to the shift).
2. Re-raise or return an error from get_credit_customers_summary instead of empty success.
3. Align Pay Due with net balance / credit redemption (or hide Apply Credit in this PaymentDialog context).
4. Add a regression test that pay_customer_due can create allocations without TypeError.

Hi @NotAbdelrahmanelsayed ,

Thank you for reaching out and sharing your thoughts. We completely understand your perspective, and we truly appreciate your passion for improving on of open source projects.

We are incredibly grateful to have skilled developers like you actively participating in our open-source ecosystem. Regarding the review times, please rest assured that the delay is not a reflection of your work or its quality. As we continuously drive the project forward, our maintainers are actively balancing a high volume of core roadmap priorities. This strategic scheduling sometimes means that community PRs take a bit longer to be evaluated and integrated as we sequence our upcoming updates.

Your contributions are highly effective and deeply valued by our team. in fact, we recently merged your PR #299!

Please don't let the natural ebb and flow of the review cycle discourage you. We absolutely want you to keep your ideas and pull requests coming. We strongly encourage you to continue supporting the BrainWise's open source repositories and the broader open-source community, as collaborative efforts from developers like you are exactly what push technology forward and make a real difference in the world!

Thank you again for your patience, your understanding, and your outstanding contributions. We will review your pending PRs as soon as they align with our current integration cycle.

@NotAbdelrahmanelsayed , also please fix checks (auto test) failings

@MohamedAliSmk pushed fixes for the three High findings:

1. pay_customer_due no longer passes pos_opening_shift to create_payment_entry — that call takes it now, matching the accepted signature.
2. get_credit_customers_summary no longer swallows exceptions into an empty "no debtors" response; errors propagate normally.
3. Pay Due now targets net_balance instead of total_outstanding, so a customer with return credit isn't asked to pay more than they actually owe. (Left "Apply Customer Credit" as-is in this dialog — it's already off by default here since allowCreditSale/allowCustomerCreditPayment aren't passed to the lump-sum PaymentDialog, so that half of the finding wasn't reachable.)

Also rebased onto develop — CI is green and the branch is conflict-free. Medium/Low items (Items on Credit overstating partial invoices, stale summary after payment, N+1 on heavy debtors, etc.) are still open; happy to take a pass at those too if useful.

@NotAbdelrahmanelsayed Thanks for the quick fixes on the high findings — the pay_customer_due / create_payment_entry signature fix, the error propagation in get_credit_customers_summary, and switching Pay Due to net_balance all look good from the technical side.

We’ll do a business review next, and merge once business approves.